Business Considerations with APIs

Introduction#

APIs are the foundation of major technology trends today. From mobile devices to cloud computing to the Internet of Things (IoT), so much relies on APIs to connect with their distributed components and deliver solutions to their respective industries. More and more enterprises are moving towards digitization, and APIs are the catalysts behind this revolution.

The role of APIs in modern business strategy#

Let's take a look at how businesses can benefit from APIs and what business strategies they can use to get ahead of the competition.

When an API is in the planning process, the business use cases must be considered a priority. Organizations that skip this will find themselves in trouble later because there are no business goals to meet. These goals can be driven by multiple factors, such as revenue, new market routes, and new products, but all of these must be outlined at the beginning so that all the decisions and choices lead toward the defined goals.

Companies focusing on successful API initiatives focus on one or more of the following factors:

• Monetizing existing assets: An API is a great multiplier for the return on investment (ROI) on the company’s assets. Let’s say that we own a house and want to rent out a room to someone to help with the bills, such as electricity and mortgage costs. Companies with existing assets can do something similar. They can expose these tech assets to the world and get an ROI through APIs. An example would be IBM selling access to Watson for data analytics.

• Connecting business domains: This usually refers to interactions across multiple lines of business. These often work independently, but can also benefit from sharing data to smooth out some processes. An example of this is Google Suite, which contains different products that cater to different domains, such as Gmail and Google Drive. APIs allow the data to be shared in a controlled and safe manner. In some cases, domains may be physical locations. Big organizations have multiple locations, including cloud and on-site data centers. These companies occasionally use APIs to secure and control the data flow between these locations.

• Self-service: The ability to extend our outreach worldwide can be made possible via a self-service portal API. Potential clients can learn about these features and services at any time, and they can integrate any of the features they need. These individual customers can then be contacted later to be able to retain them. An easy-to-integrate API is necessary for developers looking for an API, because it’s likely they’ll test the service for integrations immediately. Developers might move on to other options if they cannot integrate features quickly.

• Innovation: APIs can fuel a product's innovation by providing a simple point of access to talented developers. These developers can then build something unique and give value to the business and to end users. After making the Google Maps navigation service, Google offered their API for integration to the world. Now ride-sharing apps, for example, Uber and Lyft, rely on that API for their core business. This provides value to Google while also allowing for innovative services like Uber to exist.

• Automation: Because of APIs, big enterprise IT teams can automate data transfers between various applications. This helps to reduce the need for manual processes and custom scripts. As a result, it allows for higher business efficiency, reliability, and faster roll-outs of new solutions. This automation can help the business save funds and resources in the long run.

Note: We have mentioned some advantages above but this list can be exhaustive. For example, developer’s can enjoy increased customization when curating their applications through APIs. Furthermore, they also allow businesses and developers to save costs.

API business models#

Before we discuss the API business and monetization models, it’s important to discuss the API value chain and the roles within it:

• API providers make business assets available to consumers as an API, with certain terms and conditions.

• API consumers are developers using the API under the agreed-upon terms and conditions. They use the API to provide a service to the end users.

• End users/customers do not see the API but benefit from it by using the applications in which it is provided.

The diagram below details this relationship:

Several companies have built their business around the APIs that they provide to consumers and customers. Quite a few widely used APIs are open-sourced, but most of them are premium paid products/services that provide excellent value for their cost. Let’s take a look at some monetization options that we can pursue for our APIs:

• Free: As the name implies, there are no direct purchases made. The API must follow a business purpose even without any monetary benefit. An example of such an API would be the social login options offered by Google, Facebook, and so on. Several companies use these APIs to identify end users—this also has a benefit for the provider. Users might sign up for their platform for the convenience of using this option elsewhere. Some providers limit the calls to their API for free users to encourage developers to subscribe to their services for full access to the API.

• Developer Pays: This model charges developers for using the API. Let's look at the different ways this can be done:

  • Subscription: In this model, the provider charges directly through a subscription (monthly or yearly) for the API. Developers must be convinced of the API's value to use this model effectively. To that end, creating a sandbox where they can test out the capabilities of the API is a good option. Another way to convince developers is to use a model where the primary features will be free, with some higher-value features that will only be accessible through a subscription. This option is convenient for billing by the API provider, but the consumers might end up paying for features they never use.

  • Pay-as-you-go: This is also known as the usage-based model. The price the developer has to pay is based on how much of the API they use or how many calls they make to the API. This option is often cheaper for the consumers, but it can be challenging for the provider to bill them properly. An example of this model is the Amazon Web Services (AWS) API. AWS prompts consumers to add their credit cards, charges them monthly based on usage, and provides them with a detailed monthly report.

  • Transaction fees: This model is commonly used by payment gateways like Visa and Mastercard. They charge their consumers a fixed rate for each transaction they make. The rate is usually a percentage of the transaction being completed.

• Developer gets paid: This is an effective model when the service provider incentivizes developers to promote their product while it’s in use. This can be done in the following ways:

  • Adverts: The developers get paid to include advertisements from the API provider in their applications. In this scenario, they get paid regardless of whether an end user actually engages with the advertisements.

  • Affiliate: In this scenario, a developer gets paid whenever an end user clicks or engages with the provider's content. An example of this would be Google Adsense.

The diagram below gives us a summary of the models and their subtypes:

Performance Measures#

So far, we’ve discussed the value APIs can provide businesses and what monetization options a business can pursue to profit from APIs. However, there’s another aspect of business that we have yet to explore—the performance of the API. The business stakeholders, users, and developers might have different views about the performance and quality of the API, which might lead to conflicts between the stakeholders. For that reason, all the stakeholders must be on the same page.

For this purpose, we rely on service level indicators (SLIs), service level objectives (SLOs), and service level agreements (SLAs). They are tools that provide developers, business managers, and other stakeholders with metrics to drive business decisions about their products.

SLIs #

A service level indicator (SLI) is a carefully defined quantitative measure of an aspect of the level of service that has been provided. There are several SLIs that we can use for this. Some of them have been described in the table below:

SLOs#

A service level objective (SLO) is a target range of value for a service we measure through an SLI. An example of this structure for the request latency indicator is as follows:

In the equation above:

• $Bound_{lower}$ is the latency’s lower bound.

• $Bound_{upper}$ represent the latency’s upper bound.

Let’s take the example of the Google Search API. We want the search request latency to lie in both the lower and upper bound ranges. For instance, the search request latency should not exceed the 100 ms mark; otherwise, the Search API does not fit our business needs.

Choosing and defining such SLOs allows users to reasonably set their expectations. Without SLOs, developers may set their expectations for the performance of an API which might be at odds with those designing the service.

A good SLO should specify how it will be measured and what valid conditions it has. Let's understand this with a few examples:

• Response time of 95% of API calls < 500 ms

• The availability of the API is ≈ 98%

Choosing the right SLOs #

Choosing what SLOs to focus on has implications for the product and business. Therefore, they need the supervision of both the developer and the business stakeholders. Let's take a look at some of the factors we should consider while making these decisions:

• Keep it simple: Complicated SLIs and SLOs are harder to explain and understand and might cause issues with implementation.

• Use fewer SLOs: We should not choose more SLOs than we need to provide coverage for our system. If we can’t convince someone of the SLO’s priority, then the SLO is usually not worth focusing on at all and would only bog down development.

• Avoid absolutes:  It might be tempting to request a system that can scale in size without experiencing any latency problems and is always available. There’s a reason we strive for "highly available" and not "always available." This is because the latter is unrealistic.

SLA#

A service level agreement (SLA) is a contract that outlines the service’s terms and conditions. It also provides the service’s availability and performance, as well as other features that the customer can anticipate from the service. The SLA also defines the metrics and methods for measuring the service, such as uptime, response time, throughput, and errors. It also establishes the remedies or consequences if the service fails to meet the agreed-upon objectives. Defining SLAs should have the customer experience as the primary focus to ensure their satisfaction with the service or product.

Summary#

In this lesson, we’ve analyzed the impact of APIs on modern business and why they are integral to transforming businesses. We discussed API providers' different business models to monetize their products. Furthermore, we learned how to evaluate our API’s performance and provide metrics that are useful for all involved parties.

Quiz#

Moving forward, we’ll learn about important concepts integral to fully understanding API design.